home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5682 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.9 KB  |  95 lines
  1. Newsgroups: comp.lang.c++
  2. Path: netcom.com!marnold
  3. From: marnold@netcom.com (Matt Arnold)
  4. Subject: Re: Aborting Constructors, Part II
  5. Message-ID: <marnoldDMCK32.66r@netcom.com>
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. References: <4eoeck$t6n@news.ios.com> <4eq99t$fpu@fsuj01.rz.uni-jena.de> <marnoldDM529E.3CH@netcom.com> <mikec.823353055@atl1>
  8. Date: Tue, 6 Feb 1996 09:09:01 GMT
  9. Sender: marnold@netcom17.netcom.com
  10.  
  11. mikec@atl1.america.net (Michael J. Callahan) writes:
  12.  
  13. >>>Problem 2:  The language already provides an automatic call to delete
  14. >>>if you throw an exception from an object that was allocated using new.
  15. >>>The code above would cause delete to be called twice!  Once again, heap
  16. >>>corruption is likely.
  17. >>>
  18.  
  19. >Now how did I miss that? Through my reading I try to keep abreast of 
  20. >stds, as they evolve, but I profess ignorance of the above point. Could
  21. >you elaborate on this a little more?
  22.  
  23. (Well, it looks like you outlined it pretty well in your following text.)
  24.  
  25. >It sounds as if you are saying that the raw memory allocated for the
  26. >ctor to be run against is automatically freed by virtue of an exception
  27. >being thrown within a ctor. 
  28.  
  29. That's what I'm saying.
  30.  
  31. >Of course this seems to mean that exceptions
  32. >have to treat their invocation differently from within ctors, as versus
  33. >other placement positions in code, which implies more knowledge than I 
  34. >thought an exception had. It also seems to imply that once you have thrown
  35. >an exception in a ctor, that object no longer exists (if indeed the raw
  36. >memory for the object has automatically and unconditionly been deallocated).
  37. >I must confess I have never tried to test/access an object that threw an
  38. >exception in its ctor to see whether the object was just an invalid instance
  39. >or actually no longer existed.
  40.  
  41. Conceptually, if your throw an exception in the midst of constructing an
  42. object, it is "deconstructed" and, in a way, never existed.  The language
  43. even provides a way for all traces of failed dynamically allocated objects 
  44. to be removed, the memory allocated for them being automatically returned 
  45. to the heap.
  46.  
  47. It should be noted that, before this addition to the language, throwing a
  48. exception in the ctor of a dynamically allocated object caused a memory
  49. leak!  There was no (portable, or even palatable) way to recover the leaked 
  50. memory.  Only the language itself could plug the leak.
  51.  
  52. For example (assuming the auto-delete feature were not implemented) how 
  53. would you recover the memory leaked by the following code fragement (and it 
  54. *is* leaked)?  Assume the memory allocation succeeds but Object::Object() 
  55. throws some kind of exception...
  56.  
  57.    Object* p;
  58.  
  59.    try
  60.       {
  61.       p = new Object;
  62.       }
  63.    catch (...)
  64.       {
  65.       // now what?
  66.       }
  67.  
  68.  
  69. Hint: You can't recover it.  The main problem is that p never gets 
  70. initialized.  There's nothing in the catch block you can do to find what 
  71. value new returned.  
  72.  
  73. >So under the covers, a new allocates raw memory for the object to occupy, 
  74. >and begins running the ctor on that raw memory. Within the ctor, if an
  75. >exception is thrown, the raw memory allocation is deallocated, the instance
  76. >in effect no longer exists?
  77.  
  78. Yup. 
  79.  
  80. >Is that recent behavior to the evolving std, or did I just miss it? If 
  81. >recent, is it implemented in many compilers yet?
  82.  
  83. It's not *that* recent.  Probably not implemented in the half-baked C++
  84. compilers yet.  All I know is that Borland C++ has been doing since version 
  85. 4.0 or so.
  86.  
  87. Regards,
  88. -------------------------------------------------------------------------
  89. Matt Arnold                       |        | ||| | |||| |  | | || ||
  90. marnold@netcom.com                |        | ||| | |||| |  | | || ||
  91. Boston, MA                        |      0 | ||| | |||| |  | | || ||
  92. 617.389.7384 (h) 617.576.2760 (w) |        | ||| | |||| |  | | || ||
  93. C++, MIDI, Win32/95 developer     |        | ||| 4 3 1   0 8 3 || ||
  94. -------------------------------------------------------------------------
  95.